前言

工作幾年偶爾會看到Git commit記錄寫上了一堆bug fix或者modify UI之類的
說實在這樣寫過兩個月回去看沒有按照每一筆紀錄看過程式，根本不知道改過什麼
在第一間公司用SVN版本控管時有經過一些訓練，雖然不至於到很詳細，但至少看紀錄都猜得到是哪個方向

這邊分享的是另一種算是更進階版的紀錄，正確名稱應該叫做Git Flow
以下的範例不一定跟Git Flow 100%相同，主要是團隊參考過Git Flow一起定義出來的開發規範

開發規範

1. 所有進行開發前需要先填寫Issue，修正Bug或新增功能都要
   Bitbucket->Repository->Issues(Menu)->Create issue
   

• 修正Bug範例(kind bug)
  測試環境：發現 bug 的環境，可以是 開發/QA/Production，如果有其它環境，填寫相應的內容
  軟件版本：發現 bug 的版本
  測試時間：發現 bug 的時間
  報告者：發現 bug 的人
  操作描述：發現 bug 時進行的操作過程的描述，可以添加圖片、視頻等
  期望結果：按照正確的實現，期望上面操作的結果是什麼
  實際結果：實際測試的結果是什麼
  分析：分析出現 bug 的原因，要包括思路，和證據（比如 log 的內容，db 數據等）。這項是可選項，可以不寫。但對原因復雜的，或者查找原因的過程比較曲折
  結論：bug 發生的原因
  解決方案：修復 bug 所使用的方案
• 調整功能範例，應至少寫明調整前後的狀態，最好可以包含原因(kind enhancement)
  狀態：移除User XX狀態判斷，所有位置統一使用Role XX狀態作為判斷依據
  原因：避免規則過於複雜導致客戶難以理解
• 新功能範例，應包含新功能描述，功能特殊規則(kind enhancement)
  需求：新增設定User Pin Code功能
  規則：
  Pin Code設定判斷規則(4位數字、不得為連續數字、不得為重複數字)
  Pin Code需要透過API更新至客戶內部系統(API文件請參考 XX網址)
  資料庫XX資料表需要新增XX欄位
• 重構(kind task)
  目標：A功能與B功能都有取得XX清單功能，但條件不同，可整合至同一個Function以帶入參數的方式處理

2. 所有的Issue不直接在master/develop/release分支上進行，應另外開分支
   分支命名規則 /--
   例如：feature/issue427-marcus-new-user-status
   branch-type包含feature, release, bugfix, hotfix, try
   bugfix：修正版本的功能
   hotfix：修正以已上線版本的功能(有急迫性/嚴重Bug 會導致系統無法正常使用)
   try：可能是新技術的嘗試，不用於正式開發(可不寫issue，不能發pull request到其他分支，使用完畢就刪除)

3. 所有Commit結尾需加上 See #，這個目的是為了讓你在看Issue的時候可以關聯到所以相關的Commit紀錄

4. 在分支上開發完成後，開發工程師需要開pull request
   左側藍色框內選擇目前開發完成的分支
   右側紅色框內選擇要合併的分支，按照規範一般是會選擇develop，但也可能有特殊狀況
   中間綠色框內是選擇左側分支後，平台自動帶入的分支Commit紀錄，基本上不刪減
   下方黃色框內選擇Reviewer，基本上是Simon or Marcus
   pull request由reviewer進行code review，reviewer approve之後，由建置pull request的人負責合併
   合併完成後請刪除合併的原分支，例如：將feature/issue427-marcus-new-user-status merge至develop之後，應將feature/issue427-marcus-new-user-status branch刪除
   

5. 核心功能的Unit test，並非所有功能都要做，經由討論後決定，一般會用在主要、不常變更的功能上
   每個版本在發佈時應在Git當次版本上打印版本號的Tag

結論

剛開始用的時候其實滿不習慣的，主要是會覺得頗麻煩，但是特別在多人開發的情況下，透過Issue了解其他人到底做了什麼，每個地方到底是何時為了什麼目的而調整，優點肯定是大於缺點啊